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DETAILED ACTION 
This instant action replaced the non-final action mailed on 10/28/09 since the previously 
mailed non-final action contains typo graphical errors. Examiner hereby requests the 
applicant to disregard the previous action (mailed on 10/28/09), and consider this instant 
action. 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114 was filed in this application 
after a decision by the Board of Patent Appeals and Interferences, but before the filing of a 
Notice of Appeal to the Court of Appeals for the Federal Circuit or the commencement of a civil 
action. Since this application is eligible for continued examination under 37 CFR 1.1 14 and the 
fee set forth in 37 CFR 1 .17(e) has been timely paid, the appeal has been withdrawn pursuant to 
37 CFR 1.114 and prosecution in this application has been reopened pursuant to 37 CFR 1.114. 
Applicant's submission filed on 8/21/09 has been entered. 

Response to Arguments 

2. Applicant's arguments with respect to the amended claims have been considered but are 
moot in view of the new ground(s) of rejection. 

3. Applicant's arguments filed 8/21/09, regarding non-amended claims (i.e. original claims) 
have been fully considered but they are not persuasive since the Board of Patent Appeals and 
Interferences already affirmed the examiner rejections as proper (see BAPI decision 
(mailed date 7/1/09). Thus, examiner sustained the rejections. 
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Priority 

4. Applicant's claim for the benefit of a prior-filed application under 35 U.S.C. 1 19(e) or 
under 35 U.S.C. 120, 121, or 365(c) is acknowledged. Applicant has not complied with one or 
more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 1 19(e) as 
follows: 

The later- filed application must be an application for a patent for an invention which is 
also disclosed in the prior application (the parent or original nonprovisional application or 
provisional application). The disclosure of the invention in the parent application and in the later- 
filed application must be sufficient to comply with the requirements of the first paragraph of 35 
U.S.C. 112. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 
USPQ2d 1077 (Fed. Cir. 1994). 

The disclosure of the prior-filed application, provisional Application No. 60/176,928, 
fails to provide adequate support or enablement in the manner provided by the first paragraph of 
35 U.S.C. 1 12 for claims 1-39, 42-50, 54-65 of this application. The disclosure of the prior-filed 
application, provisional Application No. 60/176,928 series of feature requirement for Multiple 
Service Control Point (MSCP) system where 

• the first document FAST MSCP feature requirement specification Re. 3.2 discloses 
authorization, data elements, activation, invocation, normal processing, reporting 
requirements and feature interactions, 

• the second document discloses transaction detail records Rel 3.2.0, 

• the third document disclose data schema requirement for call processing control Rel. 3.2, , 
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• the fourth document discloses service administration interface Rel. 3.2, 

• fifth document discloses message and parameter specification Rel. 3.0.6 

• Sixth document discloses call flows Rel. 3.0, 

• Seventh document discloses network management requirement Rel. 3.0 

• eighth document discloses voice and telephony over ATM IWF 

• Ninth document discloses frame rely customer PVC reconfiguration 

• Tenth document discloses ATM signaling intercept processor with the GUI user guide to 
MCI WorldCOM computer system. 

These documents in provisional Application No. 60/176,928, mainly discloses generic 
specification of MSCP system that may relate to the field of invention, but there is no specific 
disclosure or clear evidence in these documents, "individually or in-combination", that provide 
adequately support or enablement in the manner provided by the first paragraph of 35 U.S. C. 112 
for the claims 1-39, 42-50, 54-65 of this instant application. 

If applicant were to disagree, it is suggest providing each document name, number, page 
number and paragraph number of the document with the corresponding claim number. 

Specification 

5. The disclosure is objected to because of the following informalities: the status of a parent 
reference U.S. applications (09/768068, 09/768077, 09/767476, 09/768069, 09/768070) recited 
in page 2, line 18 must be updated as "now issued as U.S. Patent" or "now abandoned", and it 
is also suggested to remove all attorney docket numbers for these U.S. applications since they 
now have the corresponding U.S. application numbers and/or patent numbers, respectively. 
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Appropriate correction is required. 

6. The specification is objected to as failing to provide proper antecedent basis for the 

claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the 

following is required: Claim 39 recites, "a computer readable medium" in line 1. However, the 

specification fails to provide intrinsic definition/embodiment of what a computer readable 

medium is. 



Claim Objections 

7. Claims 1, 6-14, 19, 22, 23, 27, 30, 31, 38 are objected to because of the following 
informalities: 

Claim 1 recites, both "the signaling message" and "said signaling message" as a 
antecedent basis for "a signaling message". For clarity and consistency, it is suggested to use 
either "the signaling message" or "said signaling message". 

Claims 7, 14 are also objected for the same reason as claim 1. 

Claim 6 recites "a policy condition" in line 5, and independent claim 1 also recites "a 
policy condition". For clarity and consistency, it is suggested to clarify whether they are the same 
policy or different. For the purpose of the examination, it will be assumed as "the same policy". 

Claims 7, 8, 9, 10, 11, 12, 13, 14, 19, 22, 23, 27, 30, 31, 38, are also objected for the same 
reason as claim 6. 

Claim 6 recites, "the condition" line 9, and claim 6 recites "a policy condition" in line 5, 
and independent claim 1 also recites "a policy condition". For clarity and consistency, it is 
suggested to clarify whether the condition refers to "a policy condition" in claim 6 or claim 1 . 
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For the purpose of the examination, it will assume that "the condition " refers to a condition in 
claim 6. 

Claims 7, 8, 9, 10, 1 1, 12, 13, 19, 22, 23, 27, 30, 31, 38 are also objected for the same 
reason as claim 6. 

Due to the large number of claims, examiner is hereby requesting the applicant to 
correct similar minor informalities set fort above for claims 39, 42-50, 54-65. 

Appropriate correction is required. 



Double Patenting 

The nonstatutory double patenting rejection is based on a judicially created doctrine 
grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or 
improper timewise extension of the "right to exclude" granted by a patent and to prevent possible 
harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection 
is appropriate where the conflicting claims are not identical, but at least one examined 
application claim is not patentably distinct from the reference claim(s) because the examined 
application claim is either anticipated by, or would have been obvious over, the reference 
claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re 
Goodman, 1 1 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 
USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re 
Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may 
be used to overcome an actual or provisional rejection based on a nonstatutory double patenting 
ground provided the conflicting application or patent either is shown to be commonly owned 
with this application, or claims an invention made as a result of activities undertaken within the 
scope of a joint research agreement. 

Effective January 1, 1994, a registered attorney or agent of record may sign a terminal 
disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 
3.73(b). 
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8. Claim 14 is rejected on the ground of nonstatutory obviousness-type double patenting as 
being unpatentable over claims 1-4 of U.S. Patent No. 7,283,512 (hereinafter refers to as 
Hall' 5 12) in view of Buyukkoc. 

Although the conflicting claims are not identical, they are not patentably distinct from 
each other because claim 14 of the instant application is the same scope of the claims 1-4 of the 
Patent by adding the well-known elements and functions as set forth below. 

Regarding claim 14 of the instant application, Hall'512 discloses Asynchronous 
Transfer Mode (ATM) network for effectuating intelligent policy features with respect to a call 
to be established between two parties via a virtual channel connection a calling party and a called 
party (see claim 1), comprising: 

an ATM switch serving a customer premises equipment (CPE) operated by a the calling 
party (see claim 1); 

a signaling intercept processor associated with said ATM switch the signaling intercept 
processor to for intercepting intercept a signaling message relative to said call (see claim 1); and 

a policy server associated with said signaling intercept processor, the policy profile 
database storing entries that relate subscribers to policies, where each policy identifies one or 
more policy features, a plurality of policy features, with which the related subscriber is 
associated with a subscriber (see claim 1, 2), wherein where said policy server is to: 

determine that a policy in the policy profile database is to be enforced for the calling 
party (see claim 1-4), 

execute appropriate service logic for each policy feature of the one or more policy 
features identified by the policy for the calling party (see claim 1-4), and 
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determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to said 
signaling message, a connection path being established when the policy condition for each policy 
feature, of the one or more policy features identified by the policy for the calling party, is 
determined to be satisfied (see claim 1-4). 

Hall'512 does not explicitly disclose "said policy server being associated with a policy 
profile database ". 

However, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) network (see 
FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy features with 
respect to a call to be established between a calling party and a called party (see FIG. 9, a 
connection user 904 and 902; see col. 19, line 61 to col. 20, line 24), comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by the calling party (see FIG. 9, CPE User 902 connects TDM switch 912; see 
col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch, the signaling intercept processor to intercept a 
signaling message relative to said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see 
col. 19, line 25-30; edge node send a call query/message to RSD, thus RSD intercept/capture 
the call query/message; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, said policy server being associated with a 
policy profile database ( Tables VII-IX, RSD associated with a database ), the policy profile 
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database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; 
see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents 
consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), 
where a call is associated with a user/subscriber since the user/subscriber is the one making 
the call/connect) , where each policy defines one more policy features of a group of policy 
features with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality 
of service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of 
service feature/description of a group of features/descriptions connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) where said policy server is to; 

wherein said policy server operates to effectuate a particular policy feature of the 
plurality of policy feature with respect to said call when triggered by said signaling message 
received from said signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; RSD determines/decides whether a particular/specific quality-of-service rule/policy of the 
load/congestion/priority/bandwidth/route/quality-of-service condition of a new call/connection is 
met/fulfilled when receiving setup message from a user (via RRSD)). 



Application/Control Number: 09/766,943 
Art Unit: 2463 



Page 10 



determining that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 
45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see 
col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the RSD database tables, 
deciding/determining a specific rule/policy to trigger/apply to received call's priority of 
traffic); 

execute for each policy feature of the one or more policy features identified by the policy 
for the calling party (FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 
18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 
1-16; see col. 13, line 1-6, 29-67; according to a new call, processing/executing in RSD for 
each status/feature (i.e. connectively information, threshold, quality of service, capacity, or 
status of loading/congestion) of a group of status/feature/priority (i.e. connectively 
information, threshold, quality of service, capacity, and status of loading/congestion) 
identify/recognized by the rule/policy associated with a call/connection for the 
user/subscriber); 

determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to said 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
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call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party, is determined to be 
satisfied (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 
1-65; see col. 19, line 35-50; see col. 21, line 40-50; setting/establishing the call/connection 
when load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively 
information, threshold, quality of service, capacity, or status of loading/congestion) are 
met/fulfilled for each policy/rule status/feature identified/recognized by the user/subscriber 
policy). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "said policy server being associated with a policy profile 
database ", as taught by Buyukkoc in the system of Hall'5 12, so that it would provide efficient 
means by which capacity in the network is more fully shared without adversely affecting call set 
up operations; see Buyukkoc col. 2, line 9-25. 

Moreover, the doctrine of double patenting seeks to prevent the unjustified extension of 
patent exclusivity beyond the term of a patent. 

Claim Rejections - 35 USC §101 
9. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 
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10. Claims 39, 42-50, 54-65 are rejected under 35 U.S.C. 101 because the claimed invention 
is directed to non- statutory subject matter since it fails to be limited to embodiments which fall 
within a statutory category. 

Claim 39 recites, "a computer readable medium operable with an Asynchrous Transfer 
Mode (ATM) network node, said computer-readable medium carrying a sequence of instructions 
provided for executing logic which, when executed by a processing entity. . ." in line 1-3. 

It is noted that applicant fails to provide antecedent basis for the claim terminology 
"computer readable medium" intended to be covered within the meaning in the disclosure. Since 
the applicant fails to provide antecedent basic to limit the specific statutory embodiments, 
"computer readable medium" belongs to the intrinsic non-statutory embodiments of transitory 
medium such as a carrier signal, radio wave, light wave, and transmission medium/media. 

Transitory transmission media in the context of this disclosure cover "carrier signal, 
radio wave, light wave, transmission medium/media", which are not a Manufacture within the 
meaning of 101, and electrical connections, optical coaxial cables, copper wire and fiber optics 
fibers, on which the program is still unavailable to the processor. In such embodiments, the 
program is still unable to act as a computer component and have its functionality realized. Thus, 
claims that recite nothing but the physical characteristics of a form of energy, such as a 
frequency, voltage, or the strength of a magnetic field, define energy or magnetism, per se, and 
as such are nonstatutory natural phenomena. O'Reilly, 56 U.S. (15 How.) at 1 12-14. Thus, the 
claim is also non-statutory. 

In view of the above analysis, claim 39 is ineligible for patent protection as failing to be 
limited to embodiments which fall within a statutory category. 
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Claims 42-50 and 54-65 are also rejected since they are depended upon rejection claim 39 
set forth above. 

Claim Rejections - 35 USC §103 

1 1 . The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

12. Claim 1-3, 5, 11, 12, 14-16, 18, 31, 39, 42, 43, 45, and 58 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Buyukkoc (US 6.463.062) in view of Gai (US006 167445 A). 

Regarding claim 1, Buyukkoc discloses a method in an synchronous Transfer Mode 
(ATM) network (see FIG. 7-9, a method performed by central Routing Status Database server, 
PvDS in ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 9, ATM 
switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein said ingress switch 
serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, User 
902) and said egress switch serves an egress device (see FIG. 9, Switch 914) operated by a called 
party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), the method comprising: 

receiving, in said ingress switch, a signaling message from said ingress device (see FIG. 
9, step 810, edge node receive a new call; see col. 19, line 19-26; also see FIG. 10, step 
1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 

providing said signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with said ingress switch 
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(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating said signaling message from the signaling intercept processor to a policy 
server (see FIG. 7, from regional RSD 740 (RRSD) via a link 770 to central RDS server 730, 
i.e., Signaling Control Point, SCP), said policy server being associated with a policy profile 
database ( Tables VII-IX, RSD associated with a database ), the policy profile database storing 
entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; see col. 10, line 
10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents consists 
call/connection rules/policies (e.g. features/description includes connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion), where a call is 
associated with a user/subscriber since the user/subscriber is the one making the 
call/connect) , where each policy defines one more policy features of a group of policy features 
with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality 
of service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of 
service feature/description of a group of features/descriptions connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber); 

Identifying in the policy profile database and based on the signaling message, a policy for 
the calling party (see col. 17, line 25 to col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see 
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col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
recognizing/identifying a specific rule/policy in the RSD rule/policy database tables VII- 

IX); 

determining, in the policy server and based on the signaling message, that the policy for 
the calling party is to be enforced (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; 
see col. 11, line 1-16; see col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the 
RSD database tables, deciding/determining a specific rule/policy to trigger/apply to received 
call's priority of traffic); 

executing, in said policy server and based on said signaling message for each policy 
feature of the one or more policy features identified by the policy for the calling party (FIG. 8, 
step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 
1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29- 
67; according to a new call, processing/executing in RSD for each status/feature (i.e. 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion) of a group of status/feature/priority (i.e. connectively information, 
threshold, quality of service, capacity, and status of loading/congestion) identify/recognized 
by the rule/policy associated with a call/connection for the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party , is satisfied with respect to said 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
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rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 

establishing a connection path between said ingress switch and said egress switch based 
on said determination that said policy condition is satisfied for each policy feature, of the one or 
more policy features identified by the policy for the calling party (see FIG. 8, step 850, 860, 870; 
see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, 
line 40-50; setting/establishing the call/connection when 

load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for 
each policy/rule status/feature identified/recognized by the user/subscriber policy). 

Although Buyukkoc discloses executing in said policy server for each policy feature of 
the one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches said policy server (see FIG. 4, policy server 322) being associated 
with a policy profile database (see FIG. 4, a combined system of database policy rule 414, policy 
translator, repository 326 and device-specific filtering entity 416), the policy profile database 
storing entries that relate subscriber to policies (see FIG. 4, stores data related to user policies; 
see col. 13, line 61 to col. 14, line 5), where each policy defines one more policy features of a 
group of policy features with which the related subscriber is associated (see FIG. 4, each policy 
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defines rules/policy features for a group of policy features (e.g. source address screening, 
Destination address screening features) for each user; see col. 14, line 1-15, 56 to col. 15, line 
55); 

identifying, in the policy profile database, a policy for the calling party (see FIG. 4, 
identifying/recognizing the policy for a calling user in the combined database system; see col. 
13, line 60 and col. 18, line 65); 

Determining, in the policy server and that the policy for the calling party is to enforced 
(see FIG. 4, determining the policy for the caller/user is to be managed/restricted/enforced in the 
policy server 322; see col. 13, line 60 and col. 18, line 65);; 

executing in said policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

establishing the connection path based on said determination that said policy condition is 
satisfied for each policy feature, of the one or more policy features identified by the policy for 
the calling party (see FIG. 4, establishing a connection/communication base on determination 
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that policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized 
by the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between a calling party and a called party (see 
FIG. 9, a connection user 904 and 902; see col. 19, line 61 to col. 20, line 24), comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by the calling party (see FIG. 9, CPE User 902 connects TDM switch 912; see 
col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch, the signaling intercept processor to intercept a 
signaling message relative to said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see 
col. 19, line 25-30; edge node send a call query/message to RSD, thus RSD intercept/capture 
the call query/message; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, said policy server being associated with a 
policy profile database ( Tables VII-IX, RSD associated with a database ), the policy profile 
database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; 
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see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents 
consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), 
where a call is associated with a user/subscriber since the user/subscriber is the one making 
the call/connect) , where each policy defines one more policy features of a group of policy 
features with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality 
of service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of 
service feature/description of a group of features/descriptions connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) where said policy server is to; 

wherein said policy server operates to effectuate a particular policy feature of the 
plurality of policy feature with respect to said call when triggered by said signaling message 
received from said signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; RSD determines/decides whether a particular/specific quality-of-service rule/policy of the 
load/congestion/priority/bandwidth/route/quality-of-service condition of a new call/connection is 
met/fulfilled when receiving setup message from a user (via RRSD)). 

determining that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 
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45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see 
col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the RSD database tables, 
deciding/determining a specific rule/policy to trigger/apply to received call's priority of 
traffic); 

execute for each policy feature of the one or more policy features identified by the policy 
for the calling party (FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 
18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 
1-16; see col. 13, line 1-6, 29-67; according to a new call, processing/executing in RSD for 
each status/feature (i.e. connectively information, threshold, quality of service, capacity, or 
status of loading/congestion) of a group of status/feature/priority (i.e. connectively 
information, threshold, quality of service, capacity, and status of loading/congestion) 
identify/recognized by the rule/policy associated with a call/connection for the 
user/subscriber); 

determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to said 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 
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a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party, is determined to be 
satisfied (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 
1-65; see col. 19, line 35-50; see col. 21, line 40-50; setting/establishing the call/connection 
when load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively 
information, threshold, quality of service, capacity, or status of loading/congestion) are 
met/fulfilled for each policy/rule status/feature identified/recognized by the user/subscriber 
policy). 

Although Buyukkoc discloses executing in said policy server for each policy feature of 
the one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches said policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, said policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where said policy server is 
to: 
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determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in said policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, establishing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 
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Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924 with 
memory 1 104; see col. 22, line 12-40), said computer-readable medium carrying a sequence of 
instructions provided for executing service logic which, when executed by a processing entity 
associated with said ATM network node, (see FIG. 11, see col. 22, line 12-40) causes said ATM 
network node to perform the steps of: 

receiving in said ATM network node a signaling message with respect to a call from a 
calling party (see FIG. 9, User 902; see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 
and 

identifying in the policy profile database associated with the ATM network node and 
based and based on the signaling message, a policy for the calling party (see col. 17, line 25 to 
col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, recognizing/identifying a specific 
rule/policy in the RSD rule/policy database tables VII-IX); 

the policy profile database ( Tables VII-IX, RSD associated with a database ), the policy 
profile database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, 
line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores 
contents consists call/connection rules/policies (e.g. features/description includes 
connectively information, threshold, quality of service, capacity, and/or status of 
loading/congestion), where a call is associated with a user/subscriber since the 
user/subscriber is the one making the call/connect) , where each policy defines one more 
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policy features of a group of policy features with which the related subscriber is associated (see 
col. 14, line 35-64; each rule/policy defines/describes the descriptions/features of 
connectively information, threshold, quality of service, capacity, and/or status of 
loading/congestion (i.e. a policy/rule for a quality of service feature/description of a group 
of features/descriptions connectively information, threshold, quality of service, capacity, 
and/or status of loading/congestion; a policy/rule for loading/congestion feature/description 
of a group of features/descriptions connectively information, threshold, quality of service, 
capacity, and/or status of loading/congestion) associated with a call/connection for the 
user/subscriber) 

executing, based on the signaling message, for each policy feature of the one or more 
policy features identified by the policy for the calling party (FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
processing/executing in RSD for each status/feature (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) of a group of 
status/feature/priority (i.e. connectively information, threshold, quality of service, capacity, 
and status of loading/congestion) identify/recognized by the rule/policy associated with a 
call/connection for the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to said 
signaling message ( see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
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rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 

upon determining that the policy condition associated with each policy feature of one or 
more policy feature identified by the policy for the calling party is satisfied with respect to said 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)^ 
causing a connection path to be established between the calling party and the call party (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, 
line 35-50; see col. 21, line 40-50; setting/establishing the call/connection when 
load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for 
each policy/rule status/feature identified/recognized by the user/subscriber policy). 

Although Buyukkoc discloses executing in said policy server for each policy feature of 
the one or more policy features identified by the policy for the calling party as set forth above, 
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Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches said policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, said policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where said policy server is 
to: 

determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in said policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
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identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, establishing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claims 2, 15, Buyukkoc discloses where said signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 3, 5, 16, 18, 43 and 45, Buyukkoc discloses where said signaling 
message comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which 
contains a new call requesting for a route is the SETUP/adding party message in ATM 
signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, 
line 19-25). 

Regarding claim 11, Buyukkoc discloses one ore more policy features, identified by the 
policy for the calling party, comprises an aggregated bandwidth limit feature (see col. 17, line 
30-40; see col. 13, line 45-47; total bandwidth) and 
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wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

calculating bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determining whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, 
step 840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 
25- to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
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determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps). 

Gai also discloses an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 
20; combined bandwidth processing) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 

determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 
to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA). 

Regarding claims 12, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party comprises a service class selection 
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feature (see col. 10, line 50-55; see col. 18, line 26-45; class-of-service) and where the 
determining whether a policy condition associated with each policy feature is satisfied (see FIG. 
8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, 
line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy condition/state (e.g. 
yellow, Red, and green), associated/related with connectively information, threshold, quality of 
service, capacity, or status of loading/congestion, identified/recognized by the rule/policy 
associated with a call/connection for the user/subscriber is met/fulfilled according to a new 
call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions), comprises: 

determining a requested class of service based on the signaling message 
(determining/checking a requested/demand class of service based on a new call message; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55), 

determining whether the requested class of service is permitted for a customer logical 
port with which the calling party is associated (determine/checking if a requested/demand class 
of service based is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a 
new call; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the service class selection feature when the 
requested class of service is permitted for the customer logical port with which the calling party 
is associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied 
for class of service when the requested/demand class of service is not-blocked (i.e. permitted) for 
a VPI port number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 
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Gai also discloses a service class selection feature (see col. 3, line 5-60; class/type of 
service selection/choosing) and where the determining whether a policy condition associated 
with each policy feature is satisfied (see FIG. 4, determining if a policy condition/status 
related/associated with each policy/rule feature identified/recognized by the policy/rule for the 
caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 

determining a requested class of service based on the signaling message 
(determining/calculating a request type/class of service based on request/demand; col. 3, line 5- 
65; see col. 5, line 5-45; see col. 11, line 1 to col. 12, line 40), 

determining whether the requested class of service is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
class/type of service allowed/permitted for a customer/user logical port/connection (i.e. ATM) 
with which the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see 
col. 11, line 1 to col. 12, line 40); and 

determining that the condition is satisfied for the service class selection feature when the 
requested class of service is permitted for the customer logical port with which the calling party 
is associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the called/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

Regarding claim 31, the combined system of Buyukkoc and Gai discloses all limitation 
of claim 3 1 as set forth in claim 12. Buyukkoc discloses a service class selection feature for 
specifying a service class with respect to a network port used by said party (see col. 10, line 50- 
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55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 

Regarding claim 42, Buyukkoc discloses wherein said signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claim 58, the combined system of Buyukkoc and Gai discloses all limitations 
as set forth in claim 12. Buyukkoc further discloses a service class selection feature for 
specifying a service class with respect to a network port used by said party (see col. 10, line 50- 
55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 

13. Claim 4 and 17 are rejected under 35 U.S. C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai and further in view of Noake (US006751222B1). 

Regarding claims 4 and 17, neither Buyukkoc nor Gai does not explicitly disclose a 
release message see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65). 

However, a release message is well know in the ATM signaling/SS7 in order to 
disconnect the call. 

In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 
8, line 9-39). 
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Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

14. Claims 6, 8, 9,19-21, 23-26, 46-48 and 50 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Buyukkoc in view of Gai, and further in view of Christie'656 
(US006690656B1). 

Regarding claims 6, 8, and 9, Buyukkoc discloses where said particular one or more 
policy features, identified by the policy for the calling party, comprises a address validation 
feature and where the determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) comprises 
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determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address validation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "within a range of authorized addresses ", 
"when the address, associated with the calling party, is determined to be within the range of 
authorized addresses". 

However, a source address validation/screening is well known in the ATM signaling/SS7. 

In particular, Christie'656 teaches a source address validation/screening and a destination 
address screening herein where said particular one or more policy features, identified by the 
policy for the calling party, comprises a source address validation feature (see FIG. 7, step 720, 
720, 730; policy/rule validation/verification identify the caller is the caller (source) and called 
(destination) addresses/number/IDs validation; see col. 7, line 5-55; see col. 15, line 30-60) and 
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determining whether an address associated with the calling party is within a range of 
authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining whether the caller 
address with within a range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), and 

determining that the condition is satisfied for the source address validation feature when 
the address, associated with the calling party, is determined to be within the range of authorized 
addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the status/condition is 
met/accepted/satisfied for the caller ID/number/addresses/ANI associated with the caller is 
determined to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to "within a range of authorized addresses ", "when the address, 
associated with the calling party, is determined to be within the range of authorized addresses" ., 
as taught by Christie'656 in the combined system of Buyukkoc and Gai, so that it would can 
validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39- 
45. 

Regarding claim 19, the combination of Buyukkoc, Gai and Christie'656 discloses all 
claimed limitations as set forth in claims 6, 8 and 9 above. Buyukkoc discloses accessing said 
ATM network through a particular network port associated with said CPE (see FIG. 9, accessing 
Switch 922 through the trunk/port 932; see col. 20, line 1-10). Christie'656 teaches a source 
address validation for ensuring that said party is an authorized party for accessing the ATM 
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network (see FIG. 7; see col. 7, line 9-19, 35-45; checking/validating caller number in ANI for 
verification for accessing ATM network). 

Regarding claim 20, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port (e.g. VPI port) between customer and the network). Christie'656 also 
discloses a Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 21, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claim 23 and 50, Buyukkoc discloses where said particular one or more 
policy features, identified by the policy for the calling party, comprises a address validation 
feature and where the determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) comprises 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 
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determining that the condition is satisfied for the address validation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "within a range of authorized addresses ", 
"when the address, associated with the calling party, is determined to be within the range of 
authorized addresses". 

However, a destination address validation/screening is well known in the ATM 
signaling/SS7. 

In particular, Christie'656 teaches a destination address validation/screening and a 
destination address screening herein where said particular one or more policy features, identified 
by the policy for the called party, comprises a destination address validation feature (see FIG. 7, 
step 720, 720, 730; policy/rule validation/verification identify the called (destination) 
addresses/number/IDs validation; see col. 7, line 5-55; see col. 15, line 30-60) and 

determining whether destination address associated with the called party is within a range 
of authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining whether the 
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called address with within a range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), and 

determining that the condition is satisfied for the destination address validation feature 
when the address, associated with the called party, is determined to be within the range of 
authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the 
status/condition is met/accepted/satisfied for the called ID/number/addresses/ANI is determined 
to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to "within a range of authorized addresses ", "when the address, 
associated with the calling party, is determined to be within the range of authorized addresses" ., 
as taught by Christie'656 in the combined system of Buyukkoc and Gai, so that it would can 
validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39- 
45. 

Buyukkoc does not explicitly disclose a destination address screening for defining a 
plurality of address to which said party can effectuate said call. However, a destination 
address/number validation/screening for defining a plurality of address/numbers to which said 
party can effectuate said call is well known in the signaling with SCP. In particular, Christie'656 
teaches a destination address screening for defining a plurality of address to which said party can 
effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, line 40-60; see col. 2, 
line 1-15; verifying a dial number from the list of numbers where the call needs to be connected). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
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invention was made to validate/verify dial number from the list of number to establish the call, as 
taught by Christie'656 in the system of Buyukkoc, so that it would can validate the calls and 
generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 24, the combined of Buyukkoc, Gai and Christie'656 discloses 
destination address screening feature is established for a subscriber to which said calling party 
belongs as set forth above in claim 23. 

Neither Buyukkoc nor Christie'656 explicitly discloses "a group of subscribers" . 
However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular 
policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device- 
specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a 
destination screening feature for a group of subscribers to which the party belongs (see col. 14, 
line 1-15, 56 to col. 15, line 55; applying destination addressing policy rule to a group of users 
(see FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a group of subscribers", as taught by Gai in the combined 
system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claims 25, Buyukkoc discloses wherein the ATM network further comprises: 
the policy server to: identify a policy for the called party, the policy for the called party, the 
policy of the called party include address screening feature as set forth above in claim 14. 
Buyukkoc further determine whether a 
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wherein the determining whether a policy condition associated with each address 
screening feature is satisfied with respect to signaling message, where, when determining 
whether the policy condition associated with the source address screening feature is satisfied,(see 
FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see 
col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with addressing 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection): the policy server is to 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address validation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification); 

where the connection path is established based on whether the condition is satisfied for 
the source address screening feature (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 
1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call/connection when conditions/status address checking/verification is 
met/fulfilled). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
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associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "a second policy server", "within a range 
of authorized addresses ", "when the address, associated with the calling party, is determined to 
be within the range of authorized addresses". 

However, a source address validation/screening is well known in the ATM signaling/SS7. 

In particular, Christie'656 teaches a second policy server (see FIG. 10, second 
call/connection manager (CCM) 1 115/1 120); see col. 20, line 25 to col. 21, line 60) to: a source 
address validation/screening and a destination address screening herein where said particular one 
or more policy features, identified by the policy for the calling party, comprises a source address 
validation feature (see FIG. 7, step 720, 720, 730; policy/rule validation/verification identify the 
caller is the caller (source) and called (destination) addresses/number/IDs validation; see col. 7, 
line 5-55; see col. 15, line 30-60) and 

determining whether an address associated with the calling party is within a range of 
authorized plurality of addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining 
whether the caller address with within a range of authorized numbers/IDs/ ANIs; note that a 
group or IDs/numbers/addresses/ ANIs stored in the access table is within an accessible range), 
and 

determining that the condition is satisfied for the source address validation feature when 
the address, associated with the calling party, is determined to be within the range of authorized 
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plurality of addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the 
status/condition is met/accepted/satisfied for the caller ID/number/addresses/ANI associated with 
the caller is determined to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a second policy server", "within a range of authorized 
plurality of addresses ", "when the address, associated with the calling party, is determined to be 
within the range of authorized plurality of addresses", as taught by Christie'656 in the combined 
system of Buyukkoc and Gai, so that it would can validate the calls and generate a billing record; 
see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 26, the combined of Buyukkoc, Gai and Christie'656 discloses source 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 25. 

Neither Buyukkoc nor Christie'656 explicitly discloses "a group of subscribers" . 
However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular 
policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device- 
specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a 
destination screening feature for a group of subscribers to which the party belongs (see col. 14, 
line 1-15, 56 to col. 15, line 55; applying destination addressing policy rule to a group of users 
(see FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 
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Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a group of subscribers" , as taught by Gai in the combined 
system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 46, the combined system of Buyukkoc, Gai and Christie'656 discloses 
all claimed limitations as set forth in claim 19. Buyukkoc discloses accessing said ATM network 
through a particular network port associated with said CPE (see FIG. 9, accessing Switch 922 
through the trunk/port 932; see col. 20, line 1-10). 

Regarding claim 47, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 48, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

15. Claims 7, 22 and 49 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai and further in view of Farris (US006 154445 A). 

Regarding claim 7, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party comprises a call feature (see col. 10, 
line 50-55; see col. 18, line 26-45; call/connection type feature) and where the determining 
whether a policy condition associated with each policy feature is satisfied (see FIG. 8, step 840; 
see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; 
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see col. 21, line 19-30; determines/decides whether rule/policy condition/state (e.g. yellow, Red, 
and green), associated/related with connectively information, threshold, quality of service, 
capacity, or status of loading/congestion, identified/recognized by the rule/policy associated with 
a call/connection for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
load/congestion/priority /bandwidth/routes/quality-of-service states/conditions), comprises: 

determining whether the signaling message result for a customer logical port with which 
the calling party is associated (determine/checking if a requested/demand class of service based 
is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a new call; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the call feature when the requested the 
signaling message does not result for the customer logical port with which the calling party is 
associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied for 
type of call when the requested/demand call type is not-blocked (i.e. permitted) for a VPI port 
number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses call feature (see col. 3, line 5-60; class/type of service 
selection/choosing) and where the determining whether a policy condition associated with each 
policy feature is satisfied (see FIG. 4, determining if a policy condition/status related/associated 
with each policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 

determining call type feature based on the signaling message (determining/calculating a 
request call type based on request/demand; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40), 
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determining whether the requested call type feature is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
call type allowed/permitted for a customer/user logical port/connection (i.e. ATM) with which 
the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40); and 

determining that the condition is satisfied for the call type feature when the requested call 
type feature does not result for the customer logical port with which the calling party is 
associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the called/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

Neither Buyukkoc nor Gai explicitly disclose "a maximum call attempt rate limit." 

However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "acceptable/maximum specified rate of call attempts", as 
taught by Farris in the combined system of Buyukkoc and Gai, so that it would can detect the 
predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. 

Regarding claim 22, the combined system of Buyukkoc, Gai and Farris discloses all 
claimed limitation as set forth in claim 7. Buyukkoc discloses the number of setup messages 
(see FIG. 8, steps 820,830; a message which contains a new call requesting for a route is the 
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SETUP/adding party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 
46-52; see col. 20, line 39-45; see col. 21, line 19-25). Buyukkoc discloses the number of setup 
messages as described above in claim 18. 

Regarding claim 49, the combined system of Buyukkoc, Gai and Farris discloses all 
claimed limitation as set forth in claim 22. Buyukkoc discloses the number of setup messages 
(see FIG. 8, steps 820,830; a message which contains a new call requesting for a route is the 
SETUP/adding party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 
46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

16. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai and VanDervort (US005761 191 A), or Horn (US005276676A). 

Regarding claim 10, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party, comprises a maximum size limit 
(see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call are blocked) 
and where the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 
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determining whether a size in the signaling message exceeds a limit (see col. 14, line 10- 
7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; determining/checking if the 
acceptable size/load/capacity in the new call exceed threshold) , and 

determining that the condition is satisfied for the maximum size limit feature when the 
size does not exceed the limit (see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see 
col. 21, line 30; determining the condition/status (e.g. red, yellow, green) is met/satisfied for the 
acceptable/maximum load/size/bandwidth when it does not exceed threshold). 

Gai also discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party, comprises a maximum size limit and where the determining 
whether a policy condition associated with each policy feature is satisfied comprises: 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see FIG. 4- 6, and 7A; see col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "burst". 

However, ATM network having a rule/policy/policing attribute burst size 
threshold/limiting for ATM flow control is well known in the art. 

In particular, VanDervort teaches a maximum burst size limit/threshold feature; 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see col. 6, line 8-11; limited/maximum burst size limit/threshold of user cell 
transmission for policing). 
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Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst", as taught by VanDervort in the combined system of 
Buyukkoc and Gai, so that it would control the flow of traffic and maximize the utilization of 
network resources; see VanDervort col. 6, line 1-3. 

In particular, Horn teaches a maximum burst size limit/threshold feature and determining 
that the condition is satisfied for the maximum burst size limit feature when the burst size does 
not exceed the limit (see col. 2, line 29-30; maximum burst length is limited by threshold). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst", as taught by Horn in the combined system of 
Buyukkoc and Gai, so that it would avoid overflow problem due to long bursts; see Horn col. 1, 
line 25-34. 

17. Claims 13,38, and 65 are rejected under 35 U.S. C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai and Basso (US006633539B1). 

Regarding claims 13 and 38, Buyukkoc discloses one ore more policy features, 
identified by the policy for the calling party, comprises an maximum call limit feature (see col. 
17, line 30-40; see col. 13, line 45-47; see col. 14, line 15-65; acceptable/maximum call 
load/limit/bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
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threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether maximum call limit, if a call is established between the calling party 
and called party, exceeds a requested bandwidth (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table 
VII, VIII; determining/calculating call load/limit/bandwidth is higher/exceed the 
requested/required maximum/acceptable load/limit/bandwidth), and 

determining that the condition is satisfied for the maximum call limit feature when the 
call does not exceed maximum call of calls (see col. 14, line 10-7 to col. 18, line 45; see col. 19, 
line 25- to see col. 21, line 30; Table VII, VIII; determining that the condition/status (i.e. 
red/yellow) for the acceptable/maximum call load/limit/bandwidth when the call is not 
higher/exceed the accepted/maximum calls). 

Gai also discloses maximum call limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
condition/status related/associated with each policy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises: determining whether maximum call limit, if a call is established between the calling 
party and called party, exceeds a requested bandwidth determining that the condition is satisfied 
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for the maximum call limit feature when the call does not exceed maximum call of calls (see col. 
4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65). 

Neither Buyukkoc nor Gai explicitly disclose "concurrent" . 

However, ATM network having a maximum concurrent call limit/threshed for call 
admission control (CAC) is well known in the art. In particular, Basso teaches a maximum 
concurrent call limit feature (see col. 4, line 25-35; maximum allowed/limit number of 
concurrent connection/call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "concurrent" , as taught by Basso in the combined system of 
Buyukkoc and Gai, so that it would control concurrent connections/calls to provide efficient 
protection against signaling congestion; see Basso col. 2, line 35-45. 

Regarding claim 38, the combined system of Buyukkoc, Gai and Basso discloses all 
claimed limitation as set forth in claim 13 above. Buyukkoc discloses a policy feature comprise a 
maximum call limit feature for specifying the total number of calls allowed concurrently with 
respect to a network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, 
trunk/port 932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit 
for a trunk/port). 

Regarding claim 65, the combined system of Buyukkoc, Gai and Basso discloses all 
claimed limitation as set forth in claim 38 above. 



18. Claims 27-29 and 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc and Gai, in view of Kobayashi (US 5,896,371). 
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Regarding claims 27, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party, comprises a maximum size limit 
(see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call are blocked) 
and where the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow, Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether a size in the signaling message exceeds a limit (see col. 14, line 10- 
7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; determining/checking if the 
acceptable size/load/capacity in the new call exceed threshold) , and 

determining that the condition is satisfied for the maximum size limit feature when the 
size does not exceed the limit (see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see 
col. 21, line 30; determining the condition/status (e.g. red, yellow, green) is met/satisfied for the 
acceptable/maximum load/size/bandwidth when it does not exceed threshold). 

Gai also discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party, comprises a maximum size limit and where the determining 
whether a policy condition associated with each policy feature is satisfied comprises: 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
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the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see FIG. 4- 6, and 7A; see col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai explicitly disclose "burst-sized request". 

However, limiting a burst-size request is well known in the art of ATM. In particular, 
Kobayashi teaches a maximum burst size limit feature for limiting a burst-size request associated 
with said call (see FIG. 6; see col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the 
number of cells transmitted in each call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst-sized request", as taught by Kobayashi in the 
combined system of Buyukkoc and Gai, so that it would provide a flow control performed 
cooperatively by the network and the terminal equipment and call accepted control is simplified; 
see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 28, the combined system of Buyukkoc, Gai and Kobayashi discloses all 
claimed limitations. Kobayashi discloses the number of packets per second allowed to be 
transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to col. 
13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to ATM 
network). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc and Gai, for the same 
motivation as above in claim 27. 

Regarding claim 29, the combined system of Buyukkoc, Gai and Kobayashi discloses all 
claimed limitations. Kobayashi discloses the number of packets per second allowed to be 
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received by said party from said ATM network with respect to said call (see FIG. 6; see col. 12, 
line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the combined system of Buyukkoc and Gai, 
for the same motivation as above in claim 27. 

Regarding claim 54, the combined system of Buyukkoc, Gai and Kobayashi discloses all 
claimed limitations as set forth in claim 27 above. 

Regarding claim 55, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc and Gai, for the same 
motivation as above in claim 27. 

Regarding claim 56, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the combined system of Buyukkoc and Gai, 
for the same motivation as above in claim 27. 
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19. Claim 30 and 57 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai and Smith (US006222823B1). 

Regarding claim 30, Buyukkoc discloses one ore more policy features, identified by the 
policy for the calling party, comprises an aggregated bandwidth limit feature for a particular 
network port by said calling party (see col. 17, line 30-40; see col. 13, line 45-47; total 
bandwidth; (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; col. 17, line 30-40; see 
col. 13, line 45-47; total bandwidth for the port/link) 

Where, when determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) the policy server is to: 

calculate bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determine whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, step 
840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- 
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to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determine that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps). 

Gai also discloses an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 
20; combined bandwidth processing) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 

determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 
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determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 
to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA). 

Neither Buyukkoc nor Gai explicitly disclose "authorized for use ". 

However, determining the maximum bandwidth allowable for a particular port authorized 
for use by said party is well known in the art of ATM. In particular, Smith teaches determining 
the maximum bandwidth allowable for a particular port authorized for use by said party (see 
FIG. 1-2; see col. 9, line 5-45, and abstract; determining predetermined/allowable/authorized 
bandwidth for a particular port/connection of end station). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

Regarding claim 57, the combined system of Buyukkoc, Gai and Smith discloses all 
claimed limitations as set forth in claim 30 above. 



20. Claims 32-37 and 59-64 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai and Kilkki (US006041039A). 
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Regarding claims 32-37, the combined system of Buyukkoc and Gai discloses service 
class as described above in claim 31 and 58. Buyukkoc further discloses constant bit rate service 
(CBR) and variable bit rate service (VBR) (see col. 1, line 50-60). 

Neither Buyukkoc nor Gai explicitly disclose "real-time VBR service, non-real time 
VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) ". 

However, the ATM class of services a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR) is well known in ATM standard. In 
particular, Kilkki teaches CBR, VBR, a real-time VBR service, non-real time VBR, unspecified 
bit-rate (UBR), and available bit-rate (ABR) (see col. 1, line 54-67). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide quality of service class defined by ATM standard, as taught 
by Kilkki in the combined system of Buyukkoc and Gai, so that it would provide a capability to 
manage increases in network load, supporting both real-time and non-real time application, and 
offering, in certain circumstances, a guaranteed level service quality; see Kilkki col. 1 , line 44- 
53, also by using the ATM standard services, it will enable the service provider to interoperate 
between multi-vendor networks. 

Regarding claims 59-64, the combined system of Buyukkoc, Gai and Smith discloses all 
claimed limitations as set forth in claims 32-37 above. 

21 . Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, and further in view of Noake (US006751222B1). 
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Regarding claim 44, neither Buyukkoc nor Gai explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

Conclusion 

22. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to IAN N. MOORE whose telephone number is (571)272-3085. 
The examiner can normally be reached on 7:30 AM- 4:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Derrick W. Ferris can be reached on 571-272-3 123. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
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